Troubleshooting eDirectory Performance Issues Notes

Identify Common High-Utilization Problems
High-utilization problems can be caused by many things. Almost every system that makes up the server can cause a problem. Most high-utilization problems can be solved by investigating the following:

1. Outdated Drivers and Patches
2. An Offending Process or Application
3. Operating System Issues
4. Storage System Issues
5. Storage Device and Adaptor Issues
6. Memory Issues
7. Client Issues
8. eDirectory Issues

Compression Issues
To determine if compression is causing high-utilization on an NSS volume, do the following:

1. Enter NSS /CompScreen at the server console.
2. View the NSS compression statistics and look for compression activity.
3. Enter NSS /NoBGCompression at the server console to stop compression activity.
4. Monitor the utilization value to see if it decreases.

If high utilization foes down with background compression disabled, investigate ways to move the compression burden to low-server usage periods.

eDirectory Index
To maintain a high level of performance with a large tree, eDirectory records frequently requested information and stores them in indexes. If you implement an email system for example that is integrated with eDirectory, you might wabt to create an index on the Internet Email Address attribute for user objects.

You can view the properties of each index using Index Manager. The following index types are available:

• User

User-defined, the only type that can be added using Index Manager. It can be edited and deleted.

• Auto Added

Added by eDirectory when certain attributes are created. It can be edited and deleted.

• Operational

Must be present to run the system. They cannot be edited or deleted.

• System

Must be present to run the system. They cannot be edited or deleted.

An index is an attribute on a server object in the eDirectory tree, stored in eDirectory not on the server itself. Indexes are unique to 1 server and are not shared by other servers.

Indexes can improve search performance, however additional indexes also add overhead to the server. Avoid duplicating indexes on the same partition.

The default indexes created during installation are shown in the following table:

Indexes can be managed in iManager 1.5 if the Index Management module is installed.

eDirectory Cache

Cache is data held in RAM. eDirectory reads data from disk into memory for fast retrieval. When needed, information is retrieved from cache if available, if not eDirectory gets it from disk.

eDirectory uses 2 types of cache:

• Block cache

Block cache is made up of 4KB blocks of disk data. It caches both indexes and disk blocks. Least recently used (LRU) blocks are removed from the cache first when the cache is full.

• Entry cache

Stores eDirectory entries for fast retrieval. The most recently accessed records are stored, entries are built from their blocks, it is read only.

Cache settings can be configured with iMonitor under Agent Coniguration/Database Cache.

Troubleshoot Obituaries

The obituary process is a term for the steps that eDirectory uses to synchronize old information to all servers in preparation to be purged by the replica purger process (initiated by the Janitor process).

When changes are made to eDirectory the original information is kept until those changes are synchronized to all servers in the tree that were referencing it. After that the original information can be purged from the database by the replica purger process.

The process which initiates the replica purger process, Janitor, is executed immediately after the database has been initialized successfully and scheduled to run after the inbound synchronization process has compleled.

The following actions change the distinguished name of an object and cause the creation of obituaries:

1. Renaming an entry
2. Deleting an entry
3. Moving an entry
4. Moving a subtree

There are 4 types of obituary:

1. Primary obituary types, which indicate an action on an object
2. Secondary obituary types, which indicate the servers that must be contacted and informed of the primary obituary action
3. Informational obituary types, which identify an object whose identity has been changed due to the placement of a primary obituary
4. Special case obituary types, which represent partition or internal operations that are being performed on a eDirectory object

Primary Obituary Types

When information is changed, the change is conveyed to the servers holding the affected entry by using a primary obituary type.

Secondary Obituary Types

When information is changed, the change is conveyed to the servers holding the external references of the affected entry using a secondary obituary type.

Informational Obituary Types

These obituaries are used to identify an object whose identity has been changed due to the placement of a primary obituary.

Special Case Obituary Types

These obituaries represent partition or internal operations that are being performed on an object.

Obituary Process
After an eDirectory object is renamed, deleted, or moved, the master replica holding that object initiates a 4-step process that synchronizes the old information and prepares it for purging by the replica purger process.

1. Master replica issues the obituary
2. All servers are notified of the change
3. All servers tell the master that it is OK to purge
4. The object is marked as purgeable for the replica purge process

The following table lists the 4 possible states of an obituary:

You can run an obituaries report from iMonitor, to check the status of obituaries. Because the obituary process is linked with the synchronization process, this is the first place to look for problems.